Summary
REST is resource-oriented and web-friendly. gRPC is contract-first, binary, efficient, and strong for internal service-to-service communication.
Interview Points
- REST uses HTTP semantics, resources, JSON, and broad client compatibility.
- gRPC uses Protocol Buffers and usually HTTP/2.
- gRPC supports efficient binary payloads, streaming, and generated clients.
- REST is easier for public APIs and browser usage.
- gRPC is strong for internal low-latency typed communication.
2-3 Minute Interview Script
“REST and gRPC are both valid API styles, but they optimize for different things. REST is resource-oriented, human-readable, cache-friendly, and works naturally across browsers, HTTP tooling, and public APIs.
gRPC is contract-first using Protocol Buffers. It gives strong typing, generated clients, efficient binary encoding, and streaming support over HTTP/2. That makes it very attractive for internal service-to-service communication.
The tradeoff is compatibility and operability. REST is easier to inspect and consume widely. gRPC needs tooling and may require gRPC-Web or a gateway for browser clients.
My interview answer: use REST for public and browser-facing APIs unless there is a reason not to; use gRPC internally when typed contracts, performance, and streaming matter.”
Follow-Ups
- Why is gRPC harder in browsers?
- How do you version REST vs gRPC APIs?